To aid in designing logic systems, engineers may utilize electronic design automation (EDA) software on used to design the layouts for circuit boards and integrated circuits. Both the circuit design and layout design are typically done in a hierarchical manner, building larger designs by creating instances within the larger design which instantiate smaller designs. The EDA software and the design engineers may reference a schematic design and a layout design, to generate corresponding instances (e.g., design elements) in the layout design to counterpart instances in the schematic design. Each instance within a design is an instantiation of another design; typically, instances are hardware circuits, data lanes, or groupings of hardware elements. Each instance in one of the design representations (e.g., schematic design, layout design) has a corresponding database entry containing stores various attributes about the instance. Another key component within an EDA software database is connectivity. Within a design, connectivity specifies how instances are to be connected together within the design, and which connections must be made available on the interface of design. Connectivity is represented in a design by a collection of nets. Each net has a collection of instance terminals, each instance terminal specifies which instance the net connects to and also which terminal (interface port) on the instance the net connects to. To track and “bind” instances between the schematic and layout designs, EDA software may often comprise a binder function (“binder”) that tracks, maintains, and updates the correspondences between the schematic and the layout, based on the attributes of the instances. For example, binders may try to match “name” attributes of corresponding instances across design representations, or try to dynamically match any number of other design attributes of the instances, such as the connectivity of the instances.
Although binder engines can typically maintain correspondence among instances residing on the same hierarchical level of the schematic design and layout design, conventional systems are frequently unable to effectively maintain correspondences between hierarchically disparate representations. When an engineer generates additional hierarchical levels in the layout design, the correspondences between schematic instances and layout instances are frequently broken, and, as a result, the user or connectivity driven EDA software may generate unwanted instances at unintended locations, or can delete needed layout instances in error. One reason binders are often unable to maintain correspondences between hierarchically distinct designs is that the binder is unable to infer correspondence between a schematic instance of one type, and a layout instance of another type. So when an original correspondence is between instances of, say, a PMOS circuit, the binder will be unable to maintain the correspondence when the engineer groups five PMOS circuits into a new layout design, because the PMOS circuits were replaced by a new instance for the new design, to which nothing in the schematic design accurately corresponds.
In some cases, a binder may be a name-driven binder. Name-driven binders identify correspondences between schematic instances and layout instances based upon an instance name attribute in a database. A name-driven binder can fail to maintain correspondence due to a name mismatch, which occur when hierarchical layout instance names do not correspond in some computable fashion to the hierarchical name of the schematic instance to which the instance corresponds. Unlike name-driven binders, connectivity driven binders do not require name matches, but instead rely on connectivity matching. Nevertheless, binders can fail to bind corresponding instances when the layout instances required to be bound to schematic instances are relocated into a parent or child instance having no corresponding schematic instance instantiated in the schematic design hierarchy.
FIG. 1 shows several examples of intended correspondences between instances of schematic designs 101 and instances of layout designs 110. As shown, the binder is able to identify correspondences between design instances in a “flat” schematic design 101a and a “flat” layout design 110. In other words, the binder can draw correspondences when there are no additional hierarchies to obscure instances. Frequently the binding engine can also bind instances of a hierarchical schematic design 101b with instances in a flat layout design 110b, though not always.
As described above, complications for the binder typically arise when an engineer generates a hierarchical layout design 110c, 110d. As an example, the binder is not able to bind instances of hierarchical layout 110c with instances of a flat schematic 101c. Likewise, the binder is unable to draw correspondences between instances of a hierarchical schematic 101d and a hierarchical design 110d, when the hierarchies are mismatched. Ultimately, conventional connectivity driven and name-driven binding solutions are often unable to bind instances of a hierarchical layout design 110a, 110d, when the corresponding instances are in a different hierarchical level in the schematic design 101a-d. 
When the correspondences between schematic and restructured layouts are lost, then the engineer has effectively lost the ability to make any further, meaningful modifications to the layout design, because the engineer can no longer rely on the binder to verify that the layout design is an accurate rendering of the schematic design. Moreover, automatic connectivity driven layout editors cannot automatically update the layout correctly when bindings have not been correctly computed due to mismatched hierarchy. The layout design is therefore unserviceable as a model for the circuit being designed.
To account for disparate hierarchies, some conventional solutions implement intermediate netlists that logically represent instances of the layout design in a different hierarchical level, to function as a translational file that the binder understands. When instances in the layout design are pushed to a new hierarchical level, the conventional solutions automatically restructure an intermediate netlist to have another design and instances thereof in the intermediate netlist that the binder can tracks and binds to the corresponding instance in the schematic. But tracking and maintaining an intermediate netlist can generate overhead for systems and engineers, as the intermediate netlist must be constantly updated by the connectivity driven layout editor even though it does not represent the actual schematic or the actual layout, and because the system and engineers in some solutions must administer an additional check-in/check-out policy for engineers who may want to manipulate the intermediate netlist directly. Of course, manipulating the intermediate netlist directly may also be problematic because it is a computer-generated abstraction to translate between hierarchical levels, but does not actually map to either a schematic design or layout design. Changes or errors in the intermediate netlist would be difficult to unravel, and would break the correspondences between the instances in the designs. In other words, the intermediate netlists present an unwanted administrative process on the systems and on the people, and also present a single point of error that could damage the design project in progress.
Another conventional solution frequently employed to maintain correspondences are Layout-Versus-Schematic (LVS) software modules. In operation, LVS software can compute bindings between the mismatched schematic and layout hierarchy. However, the LVS software is not typically integrated into the EDA software modules, because the LVS software presents a number of inefficiencies that would disrupt the quality and efficiency of how an EDA tool would function. These inefficiencies are due to the way the LVS software is coded and the way in which the LVS software functions. For example, LVS software products are typically batch checkers, and therefore function in a batch mode, which often require several layers of human-intervention to ensure that the finished layout design matches the schematic design. Consequently, in this example for instance, LVS software cannot be integrated into EDA software, like a connectivity-driven layout editing software, because the LVS software would be too slow for the interactive layout editing to operate in real time. Users would need to make changes and then execute the LVS software to check the entirety of the changes. What is desired, however, is a real-time, human-interactive experience. Moreover, it would be desirable to forgo the need for a separate check altogether, which would require the binder to be capable of analyzing correspondences for instances in disparate hierarchical levels.
What is needed is a means for maintaining the appropriate binding between corresponding instances of schematic and layout designs, regardless of which hierarchical level the corresponding instances reside. What is needed is a means for binding between disparate hierarchical levels, without the need for intermediate netlists.